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(54) Verfahren zur Unterstiitzung der Interaktion zwischen einer ersten und einer zweiten Einheit 



(57) Zur Unterstutzung der Interaktion zwischen 
einer ersten Einheit, die gemSB einer ersten Beschrei- 
bungssprache spezif iziert ist, und einer zweiten Einheit, 
die gemSB einer zweiten Beschreibungssprache spezi- 
fiziert ist, werden in beiden Einheiten jeweils Klassen 
zur Verfiigung gestellt werden, die die Bearbeitung von 
Typen steuern. In der ersten Einheit und/oder der zwei- 
ten Einheit werden hierbei ein oder mehrere hybride 



Klassen zur Verfugung gestellt, die jeweils sowohl die 
Bearbeitung eines gemSB der ersten Beschreibungs- 
sprache spezifiziertenTyps als auch die Bearbeitung 
eines, diesem Typ entsprechenden. in einen Typen 
gem§8 der zweiten Beschreibungssprache konvertier- 
ten Typs steuern. 
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Beschreibung 

Die Erf indung betrifft ein Verfahren zur Unterstut- 
zung der Interaktion zwischen einer ersten Einheit, die 
gemaf3 einer ersten Beschreibungssprache spezifizlert s 
ist. und einer zweiten Einheit, die gem&3 einer zweiten 
Beschreibungssprache spezifiziert ist, nach dem Ober- 
begritf von Anspruch 1, ein Verfahren zur Interaktion 
einer ersten Einheit, die gemSB einer ersten Beschrei- 
bungssprache spezifiziert ist, mit einer zweiten Einheit, io 
die gemdB einer zweiten Beschreibungssprache spezi- 
fiziert ist, nach dem Oberbegriff von Anspruch 5, ein 
Computersystem nach dem Oberbegriff von Anspruch 
7, eine Programm-Modul nach deni Oberbegriff von 
Anspruch 10 und eine Rechnereinheit nach dem Ober- is 
begriff von Anspruch 11. 

FQr die softwaremai3ige Realisierung von verteilten 
Computersystemen wird zunehmend die objektorien- 
tierte Modellierung als Architekturprinzip venwendet. 

Eine solche Software - Architektur eines Computer- 20 
systems ist die CORBA - Architektur (CORBA = Com- 
mon Object Request Broker Architecture), die eine 
bedeutende Komponente der von der Object Manage- 
ment Group (OMG) spezifizlerten OSA-Architektur 
(OSA = Object Service Architecture) ist. Objekte die 25 
dieser Spezifikation folgen, im folgenden CORBA- 
Objekte genannt. sind mittels der Beschreibungsspra- 
che CORBA IDL (IDL = interface definition language) 
spezifiziert. Auch s§mtliche Typen eines solchen Objek- 
tes sind in dieser Sprache, also CORBA IDL, spezifi- 30 
ziert. 

Fur den Bereich des Netzwerkmanagements ist 
von der OS! (Open System Interconnection) ein Objekl- 
modell standardisiert (Management framework for open 
systems interconnection, ITU-T Recommendation 35 
X.700, 1992). Seine Objekte, die im folgenden OSI- 
Objekte genannt werden, sind in der Beschreibungs- 
sprache ASN.1 (Abstract Syntax Notation) verwendet. 
Samtliche Typen eines solchen OSI-Objektes sind 
ebenfalls in dieser Sprache, also ASN.1 , spezifiziert. 40 

Die Erf indung geht nundavon aus. wie die Bearbei- 
tung von Typen in einem Computersystem normaler- 
weise realisiert ist. Fur jede Typ steht normaierweise 
eine Klasse zur Verfugung, die die Bearbeitung dieses 
einen Typs steuert. 45 

Soli nun die Interaktion zwischen Objekten, die in 
unterschiediichen Beschreibungssprachen spezifiziert 
sind. ermoglicht werden, so treten Probleme auf: Die 
Typen sind in den Objekten aLrf unterschiedliche Weise 
spezifiziert, beispielsweise in ASN. 1 in OSI-Objekten so 
und in CORBA-IDL in CORBA Objekten. Fur eine Inter- 
aktion sind deshalb Mechanismen erforderlich, die eine 
Typ-lnteroperabilitat erm6glichen. 

Der Erfindung liegt nun die Aufgabe zugrunde, die 
Interaktion zwischen Objekten. die in unterschiediichen ss 
Beschreibungssprachen spezifiziert sind. zu unterstut- 
zen. 

Diese Aufgabe wird geiost durch Verfahren nach 



der Lehre von Anspruch 1, und 5, durch ein Computer- 
system nach der Lehre von Anspruch 7, durch eine Pro- 
gramm-Modul nach der Lehre von Anspruch 10 und 
durch ein Rechnereinheit nach der Lehre von Anspruch 
11. 

Der Erfindung liegt hierbei der Gedanke zugrunde, 
daR hybride Klassen zur Verfugung gestellt werden, die 
sowohl die Bearbeitung von Typen, die gemSB einer 
ersten Beschreibungssprache spezifiziert sind als auch 
die Bearbeitung der korrespondierenden Typen gemaf3 
der zweiten Beschreibungssprache steuern. Mittels 
einer solchen hybriden Klasse kGnnen so sowohl Typen 
die in der ersten Beschreibungssprache spezifiziert sind 
im Kontext der zweiten Beschreibungssprache manipu- 
liert werden als auch umgekehrt. 

Bei solchen Typen kann es sich vorzugsweise urn 
Daten-Typen handeln. Bei Daten Typen handelt es sich 
urn Kategorisierung von zu bearbeitenden Operations- 
Argumente. die typischer Weise beides enthalten, 
sowohl das Verhalten als auch die Darstellung. 

Eine Klasse ist ein abstrakter Daten-typ, der ein 
Oder mehrere statische oder dynamische Datentypen 
und Operationen, genannt „methode", „verkapselt" 
(encapsulate) also umschlieBt. Eine Klasse ist daruber- 
hinaus eine Inplementierung, die Objekte (object 
instances), die dieser Objekt-Klasse angehdren und 
alle ein ahnliches Verhalten zeigen, erzeugen kann. 

Klassen spezifizieren Objekte entsprechend einer 
allgemeinen Implementierung. 

Ein weiterer Vorteil dieser Erfindung ist, dafi sie 
schnell ist. da Typdefinition und damit die Abbildung vor 
Programmablauf bereits erfolgt ist. Es mussen keine 
Entscheidungen wShrend des Programmablauf, bei- 
spielsweise das Abprufen von Typen, durchgef uhrt wer- 
den. 

Besonders Vorteilhaft ist es hierbei. die Erfindung 
auf den Bereich des Netzwerkmanagement anzuwen- 
den. wenn dort sowohl OSI als auch CORBA-Einheiten 
vorhanden sind. Auf Grund des hohen MaBes an Inter- 
aktion. das in einer solchen Umgebung notwendig ist. 
ist hier die Anwendung der Erfindung besonders vorteil- 
haft. 

Im Folgenden wird die Erfindung anhand eines 
Ausfuhrungsbeispiels unter Zuhilfenahme beiliegender 
Zeichnungen beispielhaft eriautert: 

Fig. 1 zeigt eine Blockschaltbild eines erfindungs- 
gemSBen Computersystems. 

Fig. 2a zeigt eine funktionelle Darstellung einer 
ersten Moglichkeit der interaktion zwischen unter- 
schiedliche spezifizierten Objekten. 

Fig. 2b zeigt eine funktionelle Darstellung einer 
zweiten Moglichkeit der Interaktion zwischen unter- 
schiedliche spezifizierten Objekten. 

Fig. 3a zeigt eine funktionelle Darstellung einer drit- 
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ten Moglichkeit der Interaktion zwischen unter- 
schiedliche spezifizierten Objekten. 

Fig. 3a zeigt eine funktionelle Darstellung einer 
vierten Moglichkeit der Interaktion zwischen unter- s 
schiedliche spezifizierten Objekten. 

Fig. 4 zeigt eine logische Darstellung des Interope- 
rabilitats-Prinzips. 

10 

In dem Ausfuhrungsbeisplel wird cfie Durchfuhrung 
der erfindunpsgemaBen Verfahren in einem erfindungs- 
gemaiBen Computersystem beschrieben, das aus 
einem Oder aus mehreren erfindungsgemSBen Rech- 
nereinheiten besteht, auf denen jeweils ein oder meh- 15 
rere erfindungsgemSBes Programm-Modul ablaufen. 

Fig. 1 zeigt ein Computersystem CS mit drei Rech- 
nereinheiten C1 bis C3. die untereinander kommunizie- 
ren. 

Bel den Rechnereinheiten C1 bis C3 handelt es 3o 
sich beispielsweise um Computer, Drucker oder um 
Netzelemente eines Kommunikationsnetzes. Sie wei- 
sen jeweils eine Hardware-Plattform, bestehend aus 
Prozessoren, Speichereinrichtungen und peripheren 
Komponenten. eine Software-Plattform. die beispiels- 25 
weise ein Betriebssystem und ein Datenbanksystem 
umfaBt und Anwendungen auf. die von auf der Soft- 
ware-Plattform ablaufenden Anwendungs-Programm- 
Modulen gebildet werden. Die Rechnereinheiten C1 bis 
C3 sind durch ein oder mehrere Kommunikationsnetze 3o 
untereinander verbunden, beispielsweise durch X.25, 
#7, Ethernt Oder Token- Ring Kommunikationssysteme. 
Die Software-Plattform der Rechnereinheiten CI bis C3 
stellt hierbei die notwendigen Datenubertragungsdien- 
ste bereit. 35 

Die Anwendungs-Programm-Module sind als 
Objekte (Managed objekt) modelliert. d. h. der Code 
und die Daten eines Objektes werden durch eine 
Summe von Attributen und Funktionen reprasentlert, 
auf die andere Objekte zugreifen kdnnen. Durch das 40 
wechselseitige Zugreifen einer Vielzahl solcher Objekte 
werden sodann die Anwendungsfunktionen des Com- 
putersystems CS erbracht. 

GemSB der CORBA-Architektur weisen die Rech- 
nereinheiten C1 bis C3 mehrere Objekte CO und SO 45 
und mehrere Objekt-Anforderungs-Broker (Object 
Request Brpker) ORB auf. 

Aus der Dienstsicht konnen die Objekte CO und SO 
jeweils als eine verkapselte Einheit betrachtet werden, 
die einen oder mehrere Dienste zur Verfugung stellt, die so 
von einem Klienten (client) angefordert werden kbnnen. 
Die Objekte CO fordern hierbei Dienste an (Client 
Object), die von den Objekten SO erbracht werden 
(Server Objects). 

Zum Anfordern eines Dienstes sendet ein CO eine 55 
Anforderungs-Nachricht (request) an ein SO. Eine sol- 
che Anforderungs-Nachricht enthalt hierbei folgende 
Informationen: eine Operation, ein Ziel-Objekt, keinen 



Oder mehrere Parameter und optional einen Anforde- 
rungs-Kontext (request context). Nach Erbringen des 
Dienstes sendet das SO eine Ergebnis-Nachricht (out- 
come) an das CO zuruck, die fur diese Anforderungs- 
nachricht def iniert ist. 

Zum Senden und zum Empfang der Anforderungs- 
und Ergebnisnachrichten steht den Objekten SO und 
CO eine Schnittstelleneinheit lU zur Verfugung. 

Die Objekt-Anforderungs-Broker (ORB) stellen eine 
Infrastruktur zur Verfugung, die es den Objekten 
eriaubt, in einer verteilten Umgebung zu kommunizie- 
ren. Fur die Objekte CO ist es damit nicht von Bedeu- 
tung auf welchem der anderen der Rechnereinheiten 
CI bis C3 ein Objekt SO, dessen Dienst sie anfordern 
wollen. angesiedelt ist und auf welcher speziellen Platt- 
form Oder in welchem Implementierungsverfahren das 
Objekt realisiert ist. 

Jedes Objekt kennt hierzu zumindest einen Objekt- 
Anforderungs-Broker ORB und weiB, wie sie diesen 
lokalen Objekt-Anforderungs-Broker zu kontaktieren 
hat. Jeder Objekt-Anforderungs-Broker weiB wie er 
andere Objekt-Anforderungs-Broker kontaktieren kann 
und wie er mit ihnen zu kommunizieren hat. Hierfur Ver- 
wendet er das RPC- Verfahren (RPC = remote proce- 
dure call mechanisms). Ein Objekt sendet somit eine 
Anforderungsnachricht und einen der Objekt-Anforde- 
rungs-Broker ORB, die Weiterreichen der Anforde- 
rungsnachricht an das Ziel-Objekt wird durch die von 
den Objekt-Anforderungs-Broker ORB gebildeten 
CORBA-lnfrastruktur eriedigt. 

Um Liber die CORBA-infrastruktur mitteis CORBA- 
Mechanismen interagieren zu konnen und mit anderen 
Objekten auf dieser Infrastruktur zusammenarbeiten zu 
kSnnen, muB jede der Objekte CO und SO uber eine 
CORBA spezifische Schnittstelle (Interface) verfugen. 
Ein solche Schnittstelle enthalt hierbei eine Beschrei- 
bung eines Satzes von mOglichen Operation, die eine 
anderes Objekt von diesem Objekt anfordern kann. Die 
Schnittstellen der Objekte sind hierbei in der Beschrei- 
bungssprache IDL (Interface Definition Language) defi- 
niert, bei der es sich um eine reine Schniffstellen- 
Beschreibungssprach handelt. Die Vererbung (inheri- 
tance) dieser Interfaces eriaubt es daB ein Objekt meh- 
rere Schnittstellen unterstOtzt. 
I 

In CORBA wird auf ein Objekt direkt iiber diese 
CORBA spezifische Schnittstelle zugegriffen. Die 
Implementierung dieser Schnittstelle ist das Object 
selbst. Es besteht aus Code und Daten und benotigt 
somit keine Ausfuhrungsinstanz (Agent entity), wie dies 
der Fall ist, wenn ein Objekt rein durch eine Datenstruk- 
tur reprasentiert ist. 

Das Computersystem enthalt nun neben den 
Objekten CO und SO weitere Objekt, die nicht in Fig. 1 
gezeigt sind. Diese sind nicht in CORBA spezif iziert und 
interagieren uber spezielle Schnittstelleneinheiten uber 
die oben beschriebene CORBA-lnfrastruktur unterein- 
ander und mit den Objekten CO und SO interagieren. 
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Die Verwendung solcher hybrider Komponenten 
auf einer CORBA-lnfrastruktur hat hierbei den Vorteil, 
daB bereits bestehende, gemaB einer anderen Objekt- 
Modell Architektur spezifizierte Objekte wiederverwen- 
det werden konnen und eine Zusammenarbeit solcher 
Objekte mit CORBA Objekten ermSglicht wird. Dies hat 
vor allem im Bereich des Netzwerkmanagement groBe 
Vorteile, da in diesem Bereich bereits eine Vielzahl von 
Objekten bestehen. die gemSB des OSi-Objektmodells 
spezifiziert sind. OSI-Netzwerkmanagent-Komponen- 
ten, beispielsweise Manager, Agent, Mediation Device, 
werden jeweils von einem oder mehreren sdche OSI- 
Objekte gebiltiet. 

FOr den Bereich des Netzwerkmanagements Ist 
von der OSI (Open System Interconnection) ein Objekt- 
model! standardislert (Management framework for open 
systems interconnection, ITU-T Recommendation 
X.700, 1992). Neben dem Objektmodell (SMI = Struc- 
ture of Management Information) sind auch grundle- 
gende Objekte, ein Set von Management Diensten 
(CMIS common management information service defi- 
nition) und ein Netzwerkmanagement-Protokoll (GMIP 
= Common Management Information Protocol) zur 
Kommunikation der Objekte untereinander spezifiziert 
Objekte sind in der Beschreibungssprache GEMO spe- 
zifiziert, die ASN Syntax venwendet und weitere eigene 
Makros enthalt 

Der Prinzipielle Unterschied zwischen „naturlichen" 
CORBA-Objekten und jiaturiichen" OSI-Objekten 
besteht darin, daB die CORBA Objekte die Implemen- 
tierung der CORBA-Schnittstelle darstellen, wohinge- 
gen die OSI-Objekte eines Netzwerkmanagement- 
selements als Datenstruktur im MIB-Datensatz (Mana- 
gement Information Base) abgelegt sind und durch 
einen Agenten, mit dem mittels des CEMIP-Protokolls 
kommuniziert wird, manipuliert werden. Daruberhinaus 
sind ihre Datentypen in unterschiedlichen Beschrei- 
bungssprachen spezifiziert. nSmiich in CORBA IDL und 
in ASN.1 und damit nicht kompatibel. 

In Fig. 2a, Fig. 2b, Fig. 3a und Rg. 3b sind nun 
mdgliche Implementierungen von OSI Einheiten auf 
einer CORBA Infrastruktur und gleichzeitig M6gliche 
Arten der Interaklion zwischen CORBA Einheiten und 
OSI Einheiten uber eine CORBA Infrastruktur aufge- 
zeigt. Die Moglichkeit der Interaktion uber eine CORBA 
Infrastruktur implizierl hierbei solch eine Interaktion zwi- 
schen Einheiten in unterschiedlicher Spezifizierungs- 
sprache. Es erfordert der gleiche Vorgehensweise. Als 
Einheit wird hierbei ein Gebilde mit einem oder mehre- 
ren Objekten betrachtet. 

Fig. 2a zeigt eine Kommunikationsschicht 
CORB/ORB, mehrere uber diese Kommunikations- 
schicht allgemein zur Verfugung stehende Dienste 
CMISE Services, zwei Netzwerkmanagement- Kompo- 
nenten M und A und jeweils zwei zwischen diesen 
Objekten und der Kommunikationsschicht CORB/ORB 
gelegenen Kommunikationsfunktionen GMO/C++ und 
CMISE/IDL. 



Bei den Komponenten M und A handelte es sich 
nicht urn CORBA-Objekte, sondern jeweils urn ein oder 
mehrere OSI- Objekten OM bzw. OA und einer Mana- 
ger bzw. Agent Funktionseinheit. Jeder der Komonen- 

5 ten M und A stelit somit eine OSI Einheit dar. Mittels der 
Agent bzw. Manger Funktionseinheit werden Operatio- 
nen auf diesen Objekten ausgeluhrt bzw. Anforderung 
an ahdere Objekte versendet. Agent und Manager 
Funktionseinheit kommunizieren uber das CMIP-Proto- 

10 koll. Aus der Sichtweise des Netzwerkmanagement 
nimmt die Komponente M die Rolle eines Managers 
(Manager) und die Komponente A die eines Agenten 
(Agent) ein. 

Die Kommunlklationseinheit GDMO/C++ besteht 

15 aus einem oder mehreren speziellen Zugriffs-Objekten, 
die die AusfOhrung von CMISE Operationen auf den 
Objekt OA oder OM ermoglichen. 

Die CMISE Management Dienste werden durch ein 
CMISE-Objekt auf der Seite des Objekles OA realisiert. 

20 Die Schnittstelleneinheit CMISE/IDL enthalt dieses 
CMISE-Objekt und die desem Objekt zugeordneten 
Dienste. Das CMISE-Objekt der Schnittstelleneinheit 
CMISE/IDL ist durch ein IDL-lnterface spezifiziert ist 
und agiert und erscheint so nach auBen wie ein 

25 CORBA-Objekt. Um diese Speziflzierung und damit die 
Bereitstellung einer CORBA-Schnittstelle zu dem 
Objekt OA zu ermdglichen. ist eine Typkonvertierung 
Oder Typ-lnteroperabiletm von ASN.1 in IDL Typen not- 
wendig. Wie diese Type-lnteroperabilitSt en-eicht wird, 

30 Wird spater anhand von Fig. 4 dargestellt. CMISE-Dien- 
ste stellen somit als ein Set von CORBA Objekten zur 
Verfugung. Durch uber die CORBA-lnfrastrukturgeleitet 
CORBA-Anforderung konnen so CMISE-Operationen 
auf dem Objekt OA ausgefuhrt werden. Gleiches gilt fur 

35 das Objekt MO. 

Eine zweite Mdglichkeit der /\nbindung von OSI- 
Einheiten uber eine CORBA-lnfrastruktur ist in Fig. 2b 
aufgezeigt 

Rg. 2b zeigt die Kommunikationsschicht 

40 CORB/ORB, mehrere uber diese Kommunikations- 
schicht allgemein zur Verfugung stehende Dienste 
CMISE Services, die Objekte OM und OA und jeweils 
zwei zwischen diesen Objekten und der Kommunikati- 
onsschicht CORB/ORB gelegenen Kommunikations- 

45 funktionen GDMO/IDL und CMISE/IDL 

Durch die Schnittstelleneinheit GDMO/IDL werden 
die in GDMO spezifizierten OSI-Objekte der Kompo- 
nenten A und M in eine Spezifikaton als IDL Schnitt- 
stelle ubersetzt. Auf ein so spezifiziertes Objekt kann 

50 durch Wassische CORBA-Nachrichten zugegriffen wer- 
den. Jedes dieser OSI-Objekt wird somit in ein reines 
CORBA Objekt transformiert. Da die Spezifikation in 
IDL und ASN.1 von unterschiedlicher Natur sind 
(Schnittstellenbeschreibung (•)Objekt-Spezifikation) ist 

55 keine vollkommene Ubersetzung moglich und nur ein 
Untermenge von CMISE-Diensten wird uber die 
Schnittstelleneinheit GDMO/IDL angeboten. Dies 
bedeute, daB nur eine Untermenge von CMISE Opera- 
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tionen auf den transformierten CORBA-Objekten aus- 
fuhrbar ist. 

In Fig. 3a und Fig. 3b sind weitere Moglichkeiten 
der Interaktion zwischen Netzwerkmanagement-Kom- 
ponenten dargestellt, wobei hier ein Gateway GATE ein- s 
gebunden wird. Die genaue Funktionsweise ergibt sich 
aus der Darstellung in den Figuren 3a und 3b zusam- 
men mit der Beschreibung der korrespondieren Einhei- 
ten, die bereits in der Beschreibung zu den Figuren 2a 
und 2b gemacht wurde. io 

Die Typinteroperabilit&t wird nun wie folgt erreicht : 

Typen im ISO Kontext sind in der Beschreibungs- 
sprache ASN.1 und Typen im CORBA Kontext in in 
der Beschreibungssprache IDL definiert. Die erfor- is 
derliche Unterstutzung fur dies Typen in jedem 
Kontext muB gesteuert werden. Diese Unterstutzen 
ist jeweils in Klassen implementiert, sowohl in 
CORBA Einheiten als auch in OSI Einheiten. Als 
Klassen werden hierbei folgende gewahit: so 

Die Klassen, die die Unterstutzung der Typen 
in der Beschreibungssprache IDL In CORBA 
Einheiten bereitstellen. Diese Klassen werden 
im folgenden lldIG Klassen genannt. Hierbei ist 25 
anzumerken, daB normalerweise eine Klasse 
fur einen Typ zustandig Ist. 

• Die Klassen. die die Unterstutzung der Typen 
In der Beschreibungssprache ASN.1 in OSI 3o 
Einheiten bereitstellen. Diese Klassen werden 
im folgenden AsnG Klassen genannt. 

Das Vorgehensweise Ist zweigeteilt. Dies wird im 
Folgenden anhand eines Sender/ EmpfSnger Paars 35 
aufgezeigt: 

Um die Behandlung von IdIG Typen in einer OSI 
Einheit zu unterstutzen, wird der korrespondie- 
rende AsnG Typ aus dem IdIG Typ konstruiert. Hier- 40 
fur wird ein ^constructor", also ein Steuerelement 
zum erzeugen eines Programm-Objekts zu der 
Klasse hinzugefugt, die den AsnG Typ unterstutzt. 
Dieser „construdor" nimmt eIne IdIG Typen als 
Parameter. Dadurch unterstutzt diese AsnG Klasse 45 
auch die Bearbeitung des korrespondlerenden IdIG 
Typs. ^ 

Um die Verwendung von AsnG Typen in einer 
CORBA Einheit zu ermoglichen, wird der AsnG Typ in so 
den korrespondlerenden IdIG Typen transformiert. Dies 
wird dadurch erreicht, daB eine neue Funktlon zu der 
Klasse hinzugefugt wird. die diesen AsnG Typen unter- 
stutzt. Diese Funktion nimmt den AsnG Typen als Para- 
meter und giebt den korrespondlerenden IdIG Typen ss 
zuruck. 

Fig. 4 zeigt nun eine loglsche Darstellung dieses 
Interoperabilitats-Prinzips; 



Fig. 4 zeigt die Einheit SEM und die Klasse GLASS. 

Die Einheit SEM sielltdie gesammte Semantik, den 
Inhalt eines Objektes. dar Ein Tell davon ist die Klasse 
CLASS, die Syntaxbeschrelbungen behandelt. Diese 
Klasse CLASS empfangt Typen unterschledlicher Syn- 
tax, Typen in der Beschreibungssprache IDL und 
ASN.1. Sle liefert unterststutzung fiir die korrspondie- 
rende unterschiedllche Typen IdIG und AsnG. Die 
Unterstutzung der IdIG Typen wird hierbei wie oben 
beschrieben bereitgestellt, Indem uber einen „constru- 
cor" IdIG Typen erzeugt und iiber ein Funktion AsnG 
Typen in IdIG Typen konvertiert werden. 

Patentanspruche 

1. Verfahren zur Unterstutzung der Interaktion zwi- 
schen einer ersten Einheit, die gem&B einer ersten 
Beschreibungssprache spezifiziert ist, und einer 
zweiten Einheit, die gemaB einer zweiten Beschrei- 
bungssprache spezifiziert Ist. wobei den beiden 
Einheiten jeweils Klassen zur Verfugung gestellt 
werden, die die Bearbeitung von Typen steuern, 
dadurch gekennzeichnet, daB der ersten Einheit 
und/oder der zweiten Einheit ein oder mehrere 
hybride Klassen zur Verfugung gest^lt werden, die 
jeweils sowohl die Bearbeitung eines gemaB der 
ersten Beschreibungssprache spezifizierten Typs 
als auch die Bearbeitung eines, diesem Typ ent- 
sprechenden, in einen Typen gemaB der zweiten 
Beschreibungssprache konvertlerten Typs steuern. 

2. Verfahren nach Anspruch 1, dadurch gekennzeich- 
net, daB als erste Spezifizierungssprache fur die 
Spezifizlerung von Typen ASN.1 verwendet wird. 

3. Verfahren nach Anspruch 1 , dadurch gekennzeich- 
net, daB als zweite Spezifizierungssprache fur die 
Spezifizlerung von Typen CORBA-IDL verwendet 
wird. 

4. Verfahren nach Anspruch 1 , dadurch gekennzeich- 
net, daB die hybride Klasse oder die hybriden Klas- 
sen ein Konvertierung zwischen Typen gemaB der 
ersten Beschreibungssprache und Typen gemaB 
der zweiten Beschreibungssprache durchfiihren. 

5. Verfahren zur Interaktion einer ersten Einheit, die 
gemaB einer ersten Beschreibungssprache spezifi- 
ziert ist, mit einer zweiten Einheit, die gemSB einer 
zweiten Beschreibungssprache spezifiziert ist, 
wobei der ersten Einheiten Klassen zur Verfugung 
gestellt werden, die die Bearbeitung von Typen 
steuern. 

dadurch gekennzeichnet, daB der ersten Einheit 
ein Oder mehrere hybride Klassen zur Verfugung 
gestellt werden, die jeweils sowohl die Bearbeitung 
eines gemaB der ersten Beschreibungssprache 
spezifizierten Typs als auch die Bearbeitung eines. 
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diesem Typ entsprechenden, in einen Typen 
gemaR der zweiten Beschreibungssprache konver- 
tierten Typs steuern. 

6. Verfahren nach Anspruch 5, dadurch gekennzeich- 5 
net, daB die erste Einheit von zumindest einem 
Objekt gebildet wird und daB die hybrids Klasse 
Oder eine der hybriden Klassen im Interface dieses 
Objektes angeboten wird. 

10 

7. Computersystem mit mindestens einer ersten Ein- 
heit, die gemaB einer ersten Beschreibungsspra- 
che spezifiziert isl und mit mindestens einer 
zweiten Einheit, die gemaB einer zweiten Beschrei- 
bungssprache speziliziert ist, wobei den beiden is 
Einheiten jeweils Klassen zur Verfugung stehen, 

die die Bearbeitung von Typen steuern, 
dadurch gekennzeichnet, daB der ersten Einheit 
und/oder der zweiten Einheit ein oder mehrere 
hybride Klassen zur Verfugung stehen. die so aus- 20 
gestaltet sind, daB sie jeweils sowohl die Bearbei- 
tung eines gemaB der ersten Beschreibungs- 
sprache spezifizierten Typs als auch die Bearbei- 
tung eines, diesem Typ entsprechenden. in einen 
Typen gemSB der zweiten Beschreibungssprache 25 
konvertierten Typs steuern. 

8. Verfahren nach Anspruch 7, dadurch gekennzeich- 
net, daB die erste Einheit eine OSi-Elnheit ist. 

30 

9> Verfahren nach Anspruch 7, dadurch gekennzeich- 
net, daS die zweite Einheit eine CORBA-Einheit ist. 

10. Programm-Modul, das gemSB einer ersten 
Beschreibungssprache spezifiziert ist und in dem 35 
ein Oder mehrere Klassen zur Verfugung stehen. 

die die Bearbeitung von Typen steuern, 
dadurch gekennzeichnet, daB in dem Programm- 
Modul ein Oder mehrere hybride Klassen zur Verfu- 
gung stehen, die so ausgestaltet sind, daB sie 40 
jeweils sowohl die Bearbeitung eines gemaB der 
ersten Beschreibungssprache spezifizierten Typs 
als auch die Bearbeitung eines, diesem Typ ent- 
sprechenden, in einen Typen gemSB der zweiten 
Beschreibungssprache konvertierten Typs steuern. 45 

11. Rechnereinheit auf der ein Programm-Modul nach 
Anspruch 10 ablauft. 
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